Mobile IPv6 (MIPv6), described in D. Johnson, C. Perkins and J. Arkko, “Mobility Support in IPv6”, RFC 3775, June 2004, allows users of mobile communications devices to move from one network to another whilst maintaining a permanent IP address, regardless of which network they are in. This allows a user to maintain connections whilst on the move. For example, if a user were participating in a Voice Over IP (VoIP) session and, during the session the user moved from one network to another, without MIPv6 support the user's IP address may change. This would lead to problems with the VoIP session.
A Mobile Node (MN) is allocated two IP addresses: a permanent home address and a care-of address (CoA). The CoA is associated with an access network, an IP subnet, which the user is currently visiting. To communicate with the MN, packets are sent to the MN home address. These packets are intercepted by a Home Agent (HA) in the MN's home network. The HA has knowledge of the current CoA. The Home Agent then tunnels the packets to the CoA of the MN with a new IP header, whilst preserving the original IP header. When the packets are received by the MN, it removes the new IP header and obtains the original IP header. The MN sends packets to another node by tunnelling them to the HA, encapsulated in packets addressed to the HA. For each packet, the HA removes the encapsulating packet, restores the original packet and forwards it to the intended destination node.
Proxy Mobile IPv6 (PMIPv6), IETF draft-sgundave-mip6-proxymip6-07, describes a Mobile Access Gateway (MAG) function. This function emulates home link properties in order to make a MN behave as though it is on its home network and allows support for mobility on networks that would not otherwise support MIPv6. A key difference between PMIPv6 and MIPv6 is that using MIPv6, a MN has control of its own mobility signalling, whereas using PMIPv6, a MN does not have control of its mobility signalling. The basic components of a PMIPv6 architecture are illustrated in FIG. 1.
A MAG 101 is usually implemented at the access router. The MAG 101 sends and receives mobility related signalling on behalf of a MN 102. When a MN 102 connects to an access router having a MAG 101, the MN 102 presents its identity in the form of a Network Access Identifier (NAI) as part of an access authentication procedure. Once the MN 102 has been authenticated, the MAG obtains the user's profile from a policy store. The MAG 101, having knowledge of the user profile and the NAI, can now emulate the MN's home network. The MN 102 subsequently obtains its home address from the MAG. The MAG 101 also informs the MN's 102 Local Mobility Anchor (LMA) 103 of the current location of the MN 102 using a Proxy Binding Update message. The Proxy Binding Update message uses the NAI of the MN 102. Upon receipt of the Proxy Binding Update message, the LMA 103 sets up a tunnel to the MAG 101 and sends a Proxy Binding Acknowledgement to the MAG. On receipt of the Proxy Binding Acknowledgement, the MAG 101 sets up a tunnel to the LMA, effectively forming a bidirectional tunnel. All traffic to and from the MN 102 is routed through the LMA 103 via the bidirectional tunnel. A MAG may serve many MNs associated with the same LMA. The MAG and the LMA do not need to have a dedicated bidirectional tunnel for each MN. Instead the same bidirectional tunnel can be used for the traffic of all the MNs that are associated with the same LMA and that are currently being served by the same MAG.
The LMA 103 intercepts any packet that is sent to the MN 102, and forwards the intercepted packet to the MAG 101 through the tunnel. On receipt of the packet, the MAG 101 removes the tunnel header and sends the packet to the MN 102. The MAG 101 acts as a default router on the access link. Any packets sent from the MN are sent via the MAG 101 through the tunnel to the LMA 103, which then sends the packet on to its ultimate destination.
Enhanced Route Optimization (ERO), described in J. Arkko, C. Vogt and W. Haddad, “Enhanced Route Optimization for Mobile IPv6”, IETF, RFC 4866, May 2007, specifies an amendment to MIPv6 route optimization. ERO secures a MN's home address against impersonation by using an interface identifier that is cryptographically and verifiably bound to the public component of the MN's public/private-key pair. ERO allows mobile and correspondent nodes to resume bidirectional communications in parallel by pursuing a care-of address test. The use of a Cryptographically Generated Address (CGA) for the MN leads to increased security and a reduction in signalling overhead. CGAs are described in T. Aura, “Cryptographically Generated Address (CGA)”, IETF, RFC 3972, March 2005.
However, ERO cannot be applied to a PMIPv6 enabled network, as according to PMIPv6, the MN should be in a “mobility unaware” state. Applying ERO on behalf of the MN in a PMIPv6 enabled network would require the MN to share its CGA private key with nodes located in visited networks (such a MAG). This is obviously undesirable from a security point of view. The fact that the MN needs to share its private key also means that the MN cannot be completely unaware of the mobility.
CGA technology is currently used in PMIPv6 enabled networks, and reduces the number of redundant mobility signalling messages, which involve the MAG, HA, LMA and CN, and so a Route Optimization mechanism for PMIPv6 that uses CGA technology would be advantageous.
It would therefore be desirable to devise a Route Optimization mechanism that uses CGA technology, and can be used for MNs in a visited network, but that does not require the MN to share its private key with other nodes in visited networks. Furthermore, in a Secure Neighbour Discovery (SeND) scenario, it would be beneficial to allow a MN in a PMIPv6 network to be able to delegate the sending of SeND messages to a proxy node such as an Access Router. “A survey of the Secure Neighbour Discovery (SeND) and Multi-Key Cryptographically Generated Addresses (MCGAs)”, Park et al, 9th International Conference on Advanced Communication Technology, Vol. 3, 12-14 February 2007, pages 2124-2127 surveys research on SeND messages.
It would be desirable for the MN to be able to delegate certain tasks to a proxy node in a secure way, for example to relieve the MN of computational/processing load. “Secure way” here means that it should be possible for a 3rd party to verify that the proxy node is authorized to perform actions on behalf of the MN and that the proxy node has agreed to do so.
A way of doing this would be that the proxy node and MN “cross-certify” each other, e.g. by signing each others public keys. This has, however, two main drawbacks. First of all, due to the generality of such an approach, it is somewhat unclear which types of tasks the MN thereby agrees to delegate. Conversely it is somewhat unclear what the proxy node has agreed to do on behalf of the MN. Secondly, it poses computational load on the MN as it needs to perform an electronic signature.